Suggestion: add a Processing row to this table — it's one of the most important behavioral differences between Global and Local events:

This is the thing users will need to understand when debugging timing or ordering issues.

The phrase "must accept the required parameters (context and, if enabled, the event data)" — "context" here refers to BuildContext which is a codegen concept. No-code users won't know what this means.

Suggest simplifying to: "This Action Block runs automatically whenever the event is triggered. If the event includes data, the Action Block must have a parameter matching the event's Data Type."

Same gap exists in the local handler setup (step 3 under "Handle the Event") — no mention of parameter matching there either.

Wait for Completion only applies to Global events. For local events, this flag has no effect at runtime — local events are always broadcast immediately to subscribers without checking this flag.

We've fixed this on the product side — the Wait for Completion field is now hidden in the UI when a local event is selected. The docs should reflect this by scoping the Wait for Completion bullet to global events only.

Suggested rewrite:

Wait for Completion (Global events only): If enabled (default), the event queue waits until the handler Action Block completes before processing the next queued event. Disable it for fire-and-forget behavior. This option is not shown for local events.

The example "before navigating away" slightly contradicts the tip on line 208 which says subscriptions auto-clean on page disposal. If navigating away already auto-cleans the subscription, why would you manually cancel before navigating?

Better example: "for example, after a certain condition is met or a toggle is switched off."

This section needs to distinguish between Global and Local event processing:

• "Events are queued and processed sequentially" is only accurate for Global events, which use a FIFO queue.
• Local events use a broadcast stream — they're delivered to all active subscribers immediately when triggered. They don't queue or wait.

Suggested rewrite for the bullets:

• Global events are queued and processed sequentially. If multiple global events are triggered quickly, they run one after another, not in parallel.
• Local events are broadcast to all active subscribers immediately when triggered.
• Wait for Completion (Global events only, enabled by default) makes the event queue wait until the handler Action Block completes before processing the next event. Disable it for fire-and-forget behavior.
• Global events always run their assigned handler, no matter where the event is triggered.
• Local event handlers exist only while their page or component is active. When the page is disposed, the subscription is automatically removed.

Naming inconsistency: this section shows space-separated names (User Logged In, Cart Updated) but earlier examples use camelCase (internetConnectionChanged, cartUpdated). FlutterFlow auto-converts display names to camelCase identifiers, but this could confuse users about what to type.

Suggest picking one convention consistently throughout — probably the display name format since that's what users actually type in the name field, with a note that the identifier is auto-generated as camelCase.

This FAQ answer only mentions waitForCompletion but doesn't clarify that Global and Local events have fundamentally different processing models. A user with mixed event types could be confused.

Suggest adding: "Also note that global events are processed sequentially through a queue, while local events are broadcast immediately to all active subscribers and do not go through the queue."